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- The MAILING DATE of this communication appears on the cover sheet with the correspondence address 
Period for Reply 



A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) FROM 
THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1 .136(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If the period for reply specified above is less than thirty (30) days, a reply within the statutory minimum of thirty (30) days will be considered timely. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 133). 
Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1.704(b). 

Status 

1 )^ Responsive to connmunication(s) filed on 13 September 2004 . 
2a)S This action is FINAL. 2b)n This action is non-final. 

3) n Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayle, 1935 CD. 1 1 , 453 O.G. 213. 

Disposition of Claims 

4) KI Claim(s) 1-4,6-8,1 0-17,37 and 39-48 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) 0 Claim(s) is/are allowed. 

6) |EI Claim(s) 1-4,6-8,10-17,37 and 39-48 is/are rejected. 

7) 0 Claim(s) is/are objected to. 

8) n Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) n The specification is objected to by the Examiner. 

10)n The drawing(s) filed on is/are: a)n accepted or b)n objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1 .85(a). 

Replacement drawing sheet(s) including the correction Is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 
11 )□ The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 

Priority under 35 U.S.C. § 119 

12)n Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 1 19(a)-(d) or (f). 
a)n All b)n Some * c)^ None of: 

1 .D Certified copies of the priority documents have been received. 

2.0 Certified copies of the priority documents have been received in Application No. . 

3.n Copies of the certified copies of the priority documents have been received in this National Stage 
application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 
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DETAILED ACTION 
Claim Rejections - 35 USC § 112 

1. The following is a quotation of the first paragraph of 35 U.S.C. 112: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention. 

2. Claims 1-4, 5-8, 10-17, 37, 39-48 rejected under 35 U.S.C. 1 12, first paragraph, as failing 
to comply with the written description requirement. The claim(s) contains subject matter which 
was not described in the specification in such a way as to reasonably convey to one skilled in the 
relevant art that the inventor(s), at the time the application was filed, had possession of the 
claimed invention. As claims 1, 16, 37, 41, 43, 46, the recitation " the request packet not 
identified router card. In the specification, page 10, lines 1-6, the request packet includes the 
port address of the router card" which is used to identify the router card. Also, see claim 11, 12, 
44, 47. 

Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

4. This application currently names joint inventors. In considering patentability of the 
claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of the various 
claims was commonly owned at the time any inventions covered therein were made absent any 
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evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1 .56 to point out 
the inventor and invention dates of each claim that was not commonly owned at the time a later 
invention was made in order for the examiner to consider the applicability of 35 U.S.C. 103(c) 
and potential 35 U.S.C. 102(e), (f) or (g) prior art under 35 U.S.C. 103(a). 
5. Claims 1-4, 6-8, 10-17, 37 and 39-48 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Hansen (US Pat. 6772204) in view of K. R. Soilings, (TFTP Protocol 
(Revision 2) (hereinaher RFC 783), and Bailey et al. (US 6,185,623). 

Regarding claims 1, 16, 37, 41, 43 and 46, Hansen discloses a method and system for 
downloading configuration file to a network device (Fig lb, Ref 26) which couples to the 
network management server. A network configuration tool "system controller" (Fig lb, Ref 10, 
28, 30 and 32) for receiving a request packet "Bootp packets" via network "bus" (col. 16, lines 
13-26, Fig lb, 29b) wherein the bootp request packet contains a destination address of a network 
device that contain configuration tool "port address" and address of the network device that send 
a request and code "file type", "the request packet not identified the network device and not 
includes a file name", the network configuration tool examines the bootp packet based on the 
destination address and code and retrieving the file name for transmitting to the network device 
via a reply message, then the network device send a new request for downloading the file by 
using a trivial file transfer protocol (TFTP). The TFTP server locates and opens this file based on 
the information provided in the TFTP request, then downloads this boot file to the network 
device based on the protocol that uses to transmit the packet "packet size" (See col. 16, lines 27- 
38 and col. 17, lines 8-38). However, Hansen fails to discloses file size, the ack, duplicating ack, 
opcode, block number, checksum of packet, active and inactive router. In the same field of 
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endeavor, RFC 783 discloses a format for TFTP packets that demonstrates a TFTP request 
packet containing a source port address and destination address in the request packet and ack 
packet and transmitting or retransmitting the packets contains the requested file between the 
devices (Pages 8-13). However, Hansen and RFC 783 fails to disclose a file size, master 
"active", slave "inactive" and determining the memory for storing the file. Li the same field of 
endeavor, Bailey discloses a system for booting a client computer fi*om a server that uses the 
TFTP. hi this system the client may include a transfer size request in the TFTP request packet, in 
which case the server responds to the request packet with the transfer size (col. 4, line 58 - col. 5, 
line 36). The purpose of requesting the transfer size is to determine the amount of memory 
needed to store a file (col. 1 1, lines 57-67). This constitutes setting up a buffer size of at least as 
large as the file size. Bailey also discloses a subnet group of clients wherein one client is the 
master client, representing the active router card of the present invention, while any other clients 
in the group represent an inactive router cards (col. 6, lines 25-40 and col. 7, Hnes 35-56). 

Since, the references suggest the use TFTP for transferring the packet between the 
devices. Therefore, it would have been obvious to one of ordinary skill in the art to apply a 
method of send the file size and file names to the MC so that the network device would be able 
to set aside enough memory to store the image file. One of ordinary skill in the art would have 
been motivated to have a group of clients containing a master client in case the group of clients 
all needed to download the same image file in order to use a common operating system as 
disclosed by Bailey's system and method into RFC 783 which teaches a method and system for 
transmitting a file between the device using TFTP into a method and system of Hansen. The 
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motivation would have been to prevent error during the configuration of the network device and 
reduce the cost of device. 

Regarding claims 2 and 17, Hansen discloses using trivial file transfer protocol (TFTP) 
to make the request for the image file (Col. 17, lines 15-30). Hansen fails to expressly disclose 
forming a data packet from the file, wherein the data packet is a fixed size and includes a system 
fi-ame header and a data packet protocol header. RFC 783 discloses that TFTP uses packets of 
fixed length blocks (page 3). Figure 3-1; Order of Headers (page 5) shows a header structure 
including Local Medium and Internet headers, which collectively represent the system frame 
header of the present invention, and Datagram and TFTP headers, which represent the data 
packet protocol header of the present invention. TFTP also specifies that each data packet must 
be acknowledged by an acknowledgement packet before the next packet can be sent (page 3). At 
the time the invention was made, it would have been obvious to a person of ordinary skill in the 
art to use the fixed size TFTP packet format with the appropriate headers in sending data packets 
formed from the requested file. One of ordinary skill in the art would have been motivated to do 
this because this protocol is small and easy to implement for the purpose of transferring files. 

Regarding claim 3, Hansen fails to disclose sending a last packet less than the fixed size. 
RFC 783 discloses that a data packet of less than 512 bytes, which is the fixed size, signals 
the termination of a transfer (page 3). At the time the invention was made, it would have been 
obvious to a person of ordinary skill in the art to use this last packet smaller that 512 bytes at the 
end of the file transfer as disclosed by RFC 783 into Hansen's system. One of ordinary skill in 
the art would have been motivated to do this to reduce the processing time at the receiving node. 

Regarding claim 4, Hansen fails to disclose retransmitting a data packet to the client if 
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the server receives a duplicate acknowledgment packet for the previous packet. RFC 783 
discloses that a lost data packet causes a timeout for the intended recipient, in which case the 
intended recipient retransmits its last packet (page 3). Thus, if the intended recipient is the chent 
and a timeout condition occurs, the client would then send an acknowledgement packet for the 
previously received data packet, i.e. a duplicate acknowledgment. At the time the invention was 
made, it would have been obvious to a person of ordinary skill in the art to retransmit a data 
packet formed from the image file in response to receiving a duplicate acknowledgement packet. 
One of ordinary skill in the art would have been motivated to do this in order to signal the server 
that a data packet has not been received and needs to be retransmitted and reducing the 
congestion at the network. 

Regarding claims 6, 40, 45 and 48, Hansen does not expressly disclose a system frame 
header and a data packet protocol header consisting essentially of an operation code, a block 
number, a file type and a checksum. RFC 783 discloses a header structure in Figure 3-1; Order 
of Headers (page 5) of Local Medium and Internet headers, which represent the system frame 
header of the present invention, and the Datagram and TFTP headers represent the data packet 
protocol header of the present invention. The format for a data packet includes an opcode and a 
block # (see Figure 5-2, page 10). Additionally, TFTP specifies that it may be implemented on 
top of the Internet User Datagram Protocol (UDP or Datagram) (page 2). The User Datagram 
Header includes a checksum (page 15). Thus, this checksum would be included in the data 
packet protocol header. RFC 783 also specifies that a request (RRQ) packet includes a filename 
in the header. It would have been obvious to a person of ordinary skill in the art to use a system 
frame header and the data packet protocol header format of a TFTP data packet in sending data 
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packets and include opcode, block number, check sum, in the header of the data packet as 
disclosed by RFC 783 into the system of Hansen. 

Regarding claim 7, Hansen fails to disclose that the acknowledgement packet consists 
essentially of a system frame header, and acknowledgement code, and a block number. RFC 783 
discloses a format for an ACK packet that contains an opcode, which represents the 
acknowledgement code, and block # (see Figure 5-3, page 10). The system frame header is 
shown in Figure 3-1 (page 5). At the time the invention was made, it would have been obvious 
to a person of ordinary skill in the art to use this format of an acknowledgement packet in 
acknowledging the received file from the server as disclosed by RFC 783 into system of Hansen. 
One of ordinary skill in the art would have been motivated to do this so that the server would 
know which packets have been sent successfiiUy and which ones need to be retransmitted. 

Regarding claims 8 and 10, Hansen discloses a media access control (MAC) address of 
the MC that is 12 characters long in hexadecimal format, or 6 bytes long if represented in binary 
(col. 16, Hne 13-26) and destination also has a MAC address. Hansen fails to disclose a system 
frame header that specifies the addresses of the router card and system controller. RFC 783 
discloses a system frame header composed of Local Medium and Internet headers (Figure 3-1, 
page 5). At the time the invention was made, it would have been obvious to send includes the 
addresses in the packet as disclosed RFC 783 into Hansen's system. One of ordinaly skill in the 
art would have been motivated to do this so that the packet would be routed to the correction 
destination NIC and that the receiving NIC was sure that this packet was coming from the server. 

Regarding claims 1 1, 12, 39, 42, 44 and 47, Hansen discloses a media access control 
(MAC) address of the MC that is 12 characters long in hexadecimal format, or 6 bytes long if 
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represented in binary (col. 16, line 13-26) and destination also has a MAC address. Hansen fails 
to disclose a system frame header that specifies the addresses of the router card and system 
controller, a request code, and a file type in the request packet. RFC 783 discloses a system 
frame header composed of Local Medium and Internet headers (Figure 3-1, page 5). RFC 783 
also discloses a request packet format that includes an opcode, which is the request code of the 
present invention, and a filename, which represents the file type of the present invention (see 
Figure 5-1, page 8). At the time the invention was made, it would have been obvious to apply 
addresses frame header, a request code as disclosed by RFC 783 into Hansen's system. One of 
ordinary skill in the art would have been motivated to do this so that the packet would be routed 
to the correction destination MC and that the receiving MC was sure that this packet was coming 
from the server. 

Regarding claims 13-15, Hansen discloses power up a network device (Col. 16, lines 13- 

26). 

Conclusion 

Any inquiry conceming this communication or earlier communications from the 
examiner should be directed to Steven HD Nguyen whose telephone number is (571) 272-3159. 
The examiner can normally be reached on 8-5. 

If attempts to reach the examiner by telephone are unsuccessfiil, the examiner's 
supervisor, Huy D Vu can be reached on (571) 272-3155. The fax phone number for the 
organization where this application or proceeding is assigned is 703-872-9306. 
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Information regarding the status of an application may be obtained from the Patent 
AppHcation Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for impublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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